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A directory dabatase system includes a network and a plurality of directory sen/ice units (DSU), 
each of the DSUs providing one or more directory service functions within the directory database. 
For propagation of an undirected user query relative to an object in the database from a source 
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its associated P table for the directory type specified in the query to generate an identification of 
one or more additional target ones of the DSUs to which the query should be directed. After 
propagating a query from the source DSU to those additional DSUs identified by the P table in 
the source DSU, there is returned to the source DSU information responsive to the user query 
from the one of the additional target DSUs containing the information. 
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© A directory dabatase system includes a network 
and a plurality of directory service units (DSU), each 
of the DSUs providing one or more directory service 
functions within the directory database. For propaga- 
tion of an undirected user query relative to an object 
2r in t" 6 database from a source DSU to one or more 
target DSUs. one of which may contain information 
Irrelative to the object, a propagation (P) table is 
Jg provided in each of the DSUs. the P tables being a 
data structure capable of determining which other 
WDSUs to send the user query to. 

The source DSU examines its associated P table 
for the directory type specified in the query to gen- 
Oerate an identification of one or more additional 
Q. target ones of the DSUs to which the query should 
111 be directed. After propagating a query from the 
source DSU to those additional DSUs identified by 
the P table in the source DSU. there is returned to 



the source DSU information responsive to the user 
query from the one of the additional target DSUs 
containing the information. 



Xera Copy Centre 



0 213 277 



API 



FIND_ELEMENT- 

(OIR. TYPE 10- 
SPECIAL. INFO 
WANTED- TAR- 
GET OSU. ...) 



RSP (TARGET- 
DSU B) 



FIHD_ELEMENT _ 
(TARGET -OSU B....) 



RSP (. . . ) 



SOURCE 
OSU A 






SPECIAL 
DIRECTORY 


NAME 

• 
• 
• 


OSU 

• 
• 
• 



TRANSPORT 
MECHANISM 



QUERY (. . .) 



V 



RPLY (.. .) 



I 




QUERY TO SPECIAL DIRECTORY FOLLOWED BY DIRECTED QUERY 

FIG. 47 



la 



1 



0 213 277 



2 



PROPAGATION APPARATUS FOR NETWORK QUERIES THROUGH SUPERIOR-SUBORDINATE AND PEER- 
PEER DATA DISTRIBUTION RELATIONSHIPS 



CROSS-REFERENCE TO RELATED APPLICA- 
TIONS 

The following copending applications, all filed 
by the same assignee as the present application, 
are related to the subject matter of this application, 
in that, they each relate, to different aspects of a 
directory database system. 

(Al) "Generalized Data Directory Moder, 
Application N° 

(A2) "Generalized Algorithmic Control Blocks 
for Sequential and Parallel Queries in Distributed 
Directory Networks", Application N° 

(A3) "Dynamic Update of Database Direc- 
tories Using Directed or Undirected Mechanisms", 
Application N° 

(A4) "Hybrid Directory Data Distribution 
Schemes for Network Topologies", Application N° 



All of these applications (filed concurrently with 
the present application) are incorporated herein by 
reference. 



Description of the Prior Art 

Distributed database management systems of- 
fer users the ability to distribute data and workload 
5 among multiple processing sites. Ideally, a distrib- 
uted database management system should support 
growth while preserving local administrative auton- 
omy and control of access to locally stored data At 
the same time, the distributed database should 
70 provide its users with a single system image such 
that although the data is distributed among several 
sites, the data distribution is transparent to the 
users who express their database accesses as 
though the data is at one place. 
is It is important to preserve the local autonomy 

of database administrators and users at each site 
of the distributed database while, at the same time, 
supporting information sharing among sites. It is to 
be expected that the equipment supporting the 
20 database at different sites will be controlled by 
different administrative entities. This expectation in- 
creases as the entry costs for computing facilities 
decline. Increased distribution of computing facili- 
ties leads to additional requirements for information 
sharing between sites to support the shared objec- 
tives and interests of the users at different sites. 
Therefore, credible access control mechanisms 
must be provided to insure isolation, when desired, 
and to control access to the shared information. At 
the same time, users must be able to easily access 
and manipulate remote data as though It were 
local. 

The distributed database management system 
architecture should preserve local control and func- 
tion when accessing local database objects. The 
fact that a site participates in the distributed 
database should not reduce that site's ability to 
perform local actions on local data by requiring the 
participation of other sites. Also, data access avail- 
ability should be a function only of the availability 
of the site(s) storing that data objects. The failure 
of one site should not impact sites which do not 
reference database objects stored (or controlled) 
by the failed site. 

Finally, it must not be difficult for an existing 
database site to join the distributed database. It 
should be fairly easy for an existing database site 
to establish the ability to access data at another 
site. The addition of another site to the distributed 
database must not require a nationwide (or global) 
system generation. 



25 

BACKGROUND OF THE INVENTION 

Field of the invention 

This invention relates to systems for propaga- 30 
tion user queries through a database network; the 
system being independent of the network topology. 
In the present application the term "directory" 
means a table of names and corresponding items 
of data. Data in a directory is locational or directive 35 
in nature, e.g. 

(1) a listing of names, addresses, and other 
data about a specific group of persons or organisa- 
tions, or 

(2) an index that is used by a control pro- 40 
gram to locate one or more blocks of data stored in 
separate areas of a data set in direct access stor- 
age, or 

(3) an index to locate blocks of program in- 
formation. The user of a directory knows the defini- 45 
tion of the object references by a name, but needs 
the specific data value(s), e.g. phone number, in 
order to perform a specific activity. 

so " 
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U.S. Patent 4*468,728 discloses data structure 
and a search method for a database management 
system in which the data structure is arranged in a 
plurality of search trees. The initial search tree and 
an initial subset of trees are maintained in a main 
fast access memory, while the remaining trees are 
kept in mass memory. An input search parameter 
is partitioned into a plurality of subparameters, one 
for each search tree. The subparameters are used 
to search a tree in each level of the data structure 
until the location of a terminating file is determined. 

An article entitled "Object Naming and Catalog 
Management For a Distributed Database Manager", 
Lindsay, 1981 IEEE, page 31, describes a system 
in which distribution of the catalog representation 
and maintenance leads to an architecture which 
supports transparent user access to data which 
may be distributed, replicated; and partitioned 
among the site of the distributed system. The ar- 
chitecture preserves individual site autonomy while 
facilitating graceful system growth. 



SUMMARY OF THE INVENTION 

The • requirements placed upon the query 
mechanism provide the rationale for the mecha- 
nisms themselves. The requirements are as fol- 
lows: 

1. Full Accessibility: This is the basic re- 
quirement It states that if a piece of information is 
stored in the directory services system, a user at 
any DSU in the system should be able to gain 
access to that information. This should be possible 
even if the user does not know precisely where that 
information is stored, or the way in which data is 
distributed through DSS. The requirement is sub- 
ject to several exceptions such as security or ac- 
cess control restrictions. However, in general, the 
design of the query mechanisms is be primarily 
driven by this requirement 

2.Subset-Ability: This requirement states that 
all DSUs participating in a DSS need not imple- 
ment the full function of the query mechanism in 
order for the first requirement to be satisfied. For 
example, small work stations in a DSS may not 
wish to act as an intermediate node in query prop- 
agation, but the users of the DSS may still require 
full accessibility. Implied in this requirement is the 
necessity for compatibility between different sub- 
sets operating within the same DSS. 

3.Performance: Performance can be mea- 
sured in many different ways. The major perfor- 
manc criteria are: 

a. Bandwidth: It is clearly d sirabl to 
minimize the number of messages sent through the 
network by the query mechanisms, thereby freeing 
network bandwidth for other purposes. 



b. Storage: Minimizing storage is particu- 
larly important in environments which consist of 
small minicomputers and/or work stations. 

•c. Delay: This refers in particular to query 
5 response times. 

The algorithms employed in the present inven- 
tion are designed, as far as possible, to minimize 
the above criteria. 

to 

BRIEF DESCRIPTION OF THE DRAWINGS 

Ftg.1 is a block diagram illustrating pro- 
cesses using a directory service system; 
75 Fig. 2 is a block diagram illustrating intercon- 

nected DSUs in a DSS; 

Fig. 3 illustrates the processing functions 
distributed in a DSS; 

Fig. 4 illustrates a two-level hybrid directory 
20 system; 

Fig. 5 shows the structure of the end user 
service P(U); 

Fig. 6 is a block diagram illustrating the 
structure of the directory function service P(F); 
25 Fig. 7 is a block diagram showing the struc- 

ture of the directory data service P(D); 

Fig. 8 illustrates the structure of the network 
service process P(N); 

Fig. 9 shows the distribution of directory 
so service processes in a DSS; 

Fig. 10 illustrates DSI request flows among 

DSPs; 

Fig. 11 illustrates the reply flows among 

DSPs; 

35 Fig. 12 is a block diagram of the overall 

structure of the system of the present invention; 

Figs. 13 and 14 illustrate the processing 
sequences for update and query propagation, re- 
spectively, in accordance with the present inven- 

40 tion; 

Fig. 15 is a representation of a typical direc- 
tory operation control block; 

Fig. 16 shows the flow of a directed query in 
accordance with the present invention; 
46 Fig. 17 illustrates the flow where a special 

directory is queried to obtain a target DSU iden- 
tification for a directed query; 

Fig. 18 shows the propagation of an un- 
directed query; 
50 Fig. 19 illustrates an example of undesired 

looping between two DSUs during a query; 

Fig. 20 shows a representative query P-table 
. (QP) and au update P-table (UP); 

Fig. 21 is a pictorial repr sentation of a 
55 Superior-Subordinate (SUP-SUB) -relationship be- 
tween DSUs; 

Fig. 22 illustrates the flow for P-table transla- 
tion for the SUP-SUB r lationship shown in Fig. 21; 
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Fig. 23 is a representation of DSUs having a 
Peer-Peer relationship to each other; 

Rg. 24 shows the P-table translation for the 
DSUs of Rg. 23; 

Rg. 25 is a representation of DSUs having a 
R plicated relationship to each other; 

Rg. 26 shows the P-table translation for the 
DSUs of Rg. 25; 

Rgs. 27-30 illustrate a number of other rela- 
tionships among other DSUs; 

Rg. 31 shows a U P-table illustrating parallel 
propagation to a number of SUP DSUs; 

Rg. 32 shows a QP-table for the parallel 
propagation to SUP and PEER DSUs; 

Rg. 33 shows a QP-table for the parallel 
propagation between SUP and PEER DSUs; 

Rg. 34 illustrates a typical query message 
propagated in accordance with the present inven- 
tion; and 

Rg. 35 shows a typical response to a query. 



DESCRIPTION OF THE PREFERRED EMBODI- 
MENT 

In the description and drawings, the following 
terms are used with the indicated meanings. 

APpl'CPtftn Interface &PQ -The protocol 
boundary between the user and the directory ser- 
vice. 

Qjrsj&ry. Service Interface fflgj) -The internal 
interface between directory service units and out- 
side services, such as communication, user ser- 
vices, or user data areas. 

Directory Service System (DSS) -An instance 
of directory service in a given network of distrib- 
uted directory services. 

Directory Service Unit (PSU) -Au unit of DSS 
that provides one or more directory service func- 
tions. 

Prior to a detailed description of the present 
invention, the following overview of the environment 
and elements of the invention are given. 

The basic structure of the directory database 
system of the present invention in shown in Rg. 
12. Rg. 12 illustrates the different interfaces or 
protocol boundaries between the DSU shown in the 
dotted enclosure and other portions ot the system. 
Theses boundaries include a user protocol bound- 
ary shown at the top of the figure, a data access 
protocol boundary at the right side of the figure 
representing the interface between the DSU and 
the database, and a communications protocol 
boundary illustrated at the bottom of the figure. 



The present structur and method is based on 
a distributi n schem wher an instance of direc- 
tory service may include on or more DSUs. Each 
DSU may perform one or more directory functions 

5 depending upon the product implementation. 

The directory servic system (DSS) shown in 
Rgure 1 is an installation of directory functions in a 
network of interconnected system. DSS provides 
the architectural directory services for the user at 

70 the API protocol boundary. The participating sys- 
tems (products) in a DSS operate coherently under 
the architected rules such as data distribution • 
schemes, naming schemes, search/update algo- 
rithms, error recovery, synchronization and the like. 

is A DSS is comprised of a collection of directory 
service units distributed troughout the intercon- 
nected system network as shown in Rgure 2. A 
DSU represents the directory service component of 
a system product implementing directory service 

20 functions. Although multiple DSUs may exist in the 
same system (product) for different applications, it 
is the intent that a single DSU can support many 
applications programs to eliminate duplication. 

25 

DSU Functions 

A DSU is composed of a set of functional 
components called directory service processes - 
30 (DSP) to provide the subsetting basis for imple- 
mentation by products. There are the following four 
types of DSPs, each of which performs distinct 
functions. 

1. User Service Process, denoted as P(U) or 
35 U, manages the interface (protocol boundary) with 

users. 

2. Directory Function Process, denoted as P- 
(F) or F, processes the directory functions to ser- 
vice the directory request using the algorithms 

40 (query/update/naming). 

3. Directory Data Service, denoted as P(D) 
or D. manages the access and maintenance of the 
directory data. 

4. Network Service Process, denoted as P- 
45 (N) or N, manages the transport network facilities to 

communicate with other DSUs. 

In order to obtain full directory service, it is not 
necessary that every DSU in the system implement 
ail DSPs. For example, a work-station may imple- 

60 ment only some of the functions and obtain full 
directory service through interaction with a larger 
system product Thus, a DSU may contain all four 
DSPs or some of the DSPs as necessary to meet 
the functional needs of each product 

55 Rgure 3 shows an example of implem ntation 
options by products in a simple n twork. DSU A 
and DSU D represent the work-station which per- 
forms the query on an as needed basis and dis- 
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cards the results f the query without r taining H in 
the storage. This type of product may not have to 
implement P(D). DSU C represents another type of 
work-station which retains the results of a query in 
its local directory. This type of product needs to 
implement P(D). DSU B represents the file server 
which acts merely as a data repository to maintain 
the master directory for the network. This type of 
product may not have to implement P(U). 



DSU Roles 

In order to perform a directory service in a 
distributed network environment several DSUs are 
generally involved and each DSU plays different 
roles. The origin or source DSU receives a direc- 
tory request from the user and originates the DSI 
request. The request is propagated through the 
intermediate DSUs as necessary to reach the tar- 
get DSU which can service the request. 



Directory Data Base 

A directory is a database that stores mappings 
from name to information related to name. The 
directory data base is a set of directories which 
contain information of a similar type. There is more 
than one member in the set if the directory data 
base is distributed across participating DSUs. The 
directory data base and all members which com- 
prise it are named via a directory type ID (Directory 
Identifier). For example, a directory database with 
directory type_JD TELEPHONE may contain name 
to telephone number mappings. A single DSU may 
maintain directories of different directory 
type_JD's, but for any given type_JD, a DSU may 
contain at most one directory. 



Directory Distribution 

Some examples of directory distribution - 
schemes are as follows: 



Centralized Directory System 

In this centralize directory system, there is a 
single master directory per directory type-ID lo- 
cated at one of the DSUs. The master directory will 
be updated whenever a change takes place. Direc- 
tory updating in such a syst m is relatively easy. 
However, there are communication costs (traffic) 



incurr d for ach query, information at ach DSU, 
as well as the communication cost for updating all 
these directories. 

5 

Hybrid Directory System 

For networks up to a few tens of DSUs, a 
single level (primitive) distribution scheme de- 

10 scribed above (that is, centralized, localized and 
distributed), is usually sufficient Beyond this num- 
ber of nodes, hybrid systems combining various 
primitive distribution schemes in a hierarchical 
manner, as illustrated in Figure 4, may be attrac- 

75 five. The hybrid multiple level design can offer both 
types of performance improvements over a single 
level design. 

The hybrid directory system is logically divided 
in subsystems, or regions, made up of any number 

20 of distributed directory services. Each subsystem 
uses different (primitive) directory distribution - 
schemes to fit into its regional environment The 
hierarchical relationships between subsystems are 
independent of the actual topology of the physical 

25 network. 



DSU-DSU Relationship 

30 A directory service can define the functional 
relationship among the DSUs distributed in the 
network due to the following aspects: 

The relationship provides a method of organizing 
35 the DSUs distributed in the network to allow the 
definition of simple and efficient protocols for the 
propagation of DSI commands such as 
query/update. In particular, the relationship can be 
used to constrain the set of DSUs to which a 
40 particular DSU can send a DSI command for 
query/update. The relationship is used to control 
how to distribute the directories, per directory type, 
among DSUs and how to maintain the respective 
directory. In some of the directory applications, the 
45 relationship of a particular set of DSUs might re- 
flect the organisation structure of the entreprise 
owning the network, even though the network topol- 
ogy does not 

50 

DSU-DSU Communication 

The lines joining the DSUs in Figure 2 indicate 
the communication paths. Communication between 
55 DSUs may be accomplished through the use of 
any one of several different transport mechanisms. 
For example, DSUs may communicate with each 
other by running as a set of transaction models 
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using IBM's. System Network Architecture (SNA) or 
equivalent level of transport facilities. In this case, 
the lines represent sessions and may not resemble 
in any way the physical topology of the network. 
The only assumption that the directroy service 
structure makes about the nature of the transport 
mechanism is that it provides guaranteed error-free 
delivery of data from source to destination. 



User DSU Interface 

The user makes a directory function request by 
way of the API verbs to one of the DSUs. The 
-requested DSU interacts with other remote DSUs, 
and then provides the appropriate response to the 
user. 



DIRECTORY SERVICE PROCESS (DSP) 

This section describes the functions and struc- 
ture of each DSP. In practice, the DSPs may be 
implemented either in programming or by a micro- 
processor. 



End User Service Process P(U) 

The P(U) basically manages the protocol 
boundary to service the end user request. Only P* 
(U) interfaces with the API, thus shielding other 
DSPs from the end user. At the request of the end 
user. P(U) parses the received verbs and sends the 
directory request to P(F) for the 
information/response ponse. When it receives the 
information/response from P(F), it returns it to user 
to satisfy the original API verb. 



Structure of P(U) 

As shown in Fig. 5, P{U) consists of a set of 
API vert) processors, each of which has two com- 
ponents (API send processor and API receive pro- 
cessor). The API send processor is to parse the 
API verbs and its associated parameters from the 
user and construct the DSI request encoding to be 
sent to P(F) for specific directory tasks as re- 
quested in the API verbs. The API receive proces- 
sor is to decode the received DSI replies and 
present the information/data (carried in the reply) to 
the user protocol boundary according to the de- 
fined API rules. 



Directory Function Service: P(F) 

Th P(F) performs the ssence of distributed 
directory functions such as search/update algo- 
s . rithms and naming algorithm. P(F) is knowledge- 
able of the existence of distributed directories and 
name database (if any), and it provides a focal 
point for maintaining currency among them in the 
system. 

70 The P(F) is responsible for providing the in- 
formation response satisfying the request from P- 
(U). P(F) maintains/ manages the directory opera- 
tion control block to be used by the directory 
algorithm facilities. The control block contains the 

75 algorithm control information such as affinity lists. 
P(F) uses this information to determine the best 
way to get information and respond to the requests 
from P(U). P(F) interacts with other remote P(F)s as 
necessary to locate the target P(F) (that is, the P- 

20 (F) directly linked to the P(D) which can access 
requested directory data). The target P(F) obtains 
the directory data from the D (P), and sends it to 
the source P(F) (that is, the P(F) that originally 
received a request from P(U)). Then the source P- 

25 (F) passes the directory data to the P(U) that 
originated the request P(F) is the bridge form of 
service interacting with both P(U) and P(D), as well 
as P(N). 

30 

Structure of P(F) 

As shown in Fig 6, P(F) consists of a set of DSI 
command processors, each of which has two com- 

35 ponents (DSI request processor and DSI reply pro- 
cessor) to process the received requests and re- 
plies respectively. The format of the input to the P- 
(F) should preserve the DSI command construct 
regardless of whether the command is received 

40 from the P(U) or the remote P(F)s through the 
communication network. 

The DSI request processor the DSI processes 
the DSI requests received from either P(U) or re- 
mote DSUs. tt uses the directory algorithm facilities 

45 such as the query/update propagation algorithm 
and the name assignment algorithm as appropriate. 
The directory algorithms determine the target DSU 
which can provide the requested information. If the 
receiving DSU is determined to be the target DSU, 

so the DSI request processor fetches the requested 
information by way of P(D) and sends the DSI 
reply carrying that information to the origin DSU. 
Otherwise, the DSI request processor passes the 
received requ st to the other DSU as the algorithm 

55 determines, based on the affinity lists of th opera- 
tion control block. 
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The DSI reply processor processes the DSj 
replies which carry th information requested by 
the OSI requests. If the receiving DSU is the origin 
DSU (which originated the DSI request), the DSI 
reply processor passes it to the local P(U). Other- 
wise, it sends the received DSI reply toward the 
origin DSU. 



Directory Data Service: P(D) 

The PP) manages the directory data access 
protocol boundary to access and maintain the di- 
rectory data. Only P(D) has knowledge of the struc- 
ture of the directory contents by way of the direc- 
tory descriptors specified by the users, thus shield- 
ing other DSP's from the directory data structures. 

The P(D) receives the directory data request - 
(query, update and so on) from P(F), performs the 
appropriate operation on the directory data by way 
of the data access protocol boundary and responds 
as appropriate to the P(F). It is the responsibility of 
P(F) to locate the target P(D) (that is. the P(D) 
maintaining the requested directory data) before 
sending a request to that P(D). 



Structure of P(D) 

As shown in Rg. 7, the P(D) consists of two 
processors, Read and Write. The read processor 
services the DSI requests (for example, query), 
from P(F), which requires reading the directory 
data through the data access protocol boundary. It 
reads the requested directory data according to the 
directory descriptors and returns the retrieved data 
by way of the appropriate DSI reply to P(F). The 
write processor services the DSI requests (for ex- 
ample, update), from P(F), which requires writing 
the directory data through the data access protocol 
boundary. It performs the directory data update as 
requested, according to the directory descriptors, 
and returns the results, If necessary, via the appro- 
priate DSI reply. 



Directory Network Service: P(N) 

The P(N) provides the ability to send and re- 
ceive the DSI commands between DSUs. It inter- 
faces with the transport mechanism used for DSU- 
DSU communication, thus shielding other DSP's 
from the networking function. P(N) controls the 
network protocol boundaries to achieve the P(F) to 
P(F) conversation between remote DSUs. The con- 
tent of DSI request/replies are basically transparent 
to P(N), and the function of P(N) is merely to 
deliver the DSI requests/replies to the remote P(F> 



's through the network. Also, the P(N) does not 
determine where to send queries or updates. This 
is determined by the propagation algorithm in the 
P(F). 

5 

Structure of P(N) 

As illustrated in Rg. 8, the P(N) consists of two 
io processors, send and receive. The send processor 
is to control the sending of data in a DSU-DSU 
communication. The receive processor is to receive 
data from the DSU-DSU communication. The func- 
tions of these processors have direct dependencies 
is on the protocol boundary of the network used for 
DSU-DSU communication. The directory structure 
describes the specific functions of P(N) required to 
use the DSU-DSU transport mechanisms. 

20 

Structure of P(F) 

As shown in Rg. 6, P(F) consists of a set of 
DSI command processors, each of which has two 

25 components (DSI) request processor and DSI reply 
processor) to process the received requests and 
replies respectively. The format of the input to the 
P(F) should preserve the DSI command construct 
regardless of whether the command is received 

a? from the P(U) or the remote P(F)s through the 
communication network. 

The DSI request processor processes the DSI 
requests received from either P(U) or remote 
DSUs. It uses the directory algorithm and the name 

35 assignment algorithm as appropriate. The directory 
algorithms determine the target DSU which can 
provide the requested information. If the receiving 
DSU is determined to be the target DSU, the DSI 
request processor fetches the requested informa- 

40 tion by way of P(D) and sends the DSI reply 
carrying that information to the origin DSU. Other- 
wise, the DSI request processor passes the re- 
ceived request to the other DSU as the algorithm 
determines, based on the affinity lists of the opera- 

45 tion control block. 

The DSI reply processor processes the DSI 
replies which carry the information requested by 
the DSI requests. If the receiving DSU is the origin 
DSU (which originated the DSI request), the DSI 

so reply processor passes it to the local P(U). Other- 
wise, it sends the received DSI reply toward the 
origin DSU. 
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Directory Data Service: P(D) 

The P(D) manages the directory data access 
protocol boundary to access and maintain the di- 
rectory data. Only P(D) has knowledge of the struc- 
ture of the directory contents by way of the direc- 
tory descriptors specified by the users, thus shield- 
ing other DSP's from the directory data structures. 

The P(D) receives the directory data request - 
(query, update and so on) from P(F), performs the 
appropriate communication. The functions of these 
processors have direct dependencies on the pro- 
tocol boundary of the network used for DSU-DSU 
communication. The directory structure describes 
the specific functions of P(N) required to use the 
DSU-DSU transport mechanisms. 



Relationships Between DSPs 

A DSS can be viewed as a collection of an 
arbitrary number of P(U)s. P(F)s t P(D)s and P(N)s - 
(Figure 9). A DSU must contain at least a P(F) and 
a P(N), although the levels of complexity of the 
functions to be performed vary depending on the 
roles of the DUS within a DSS. DSI commands are 
used as the message units to carry information 
from one DSP to another. There are two types of 
DSI commands, DSI request dans DSI reply. The 
DSI request is used to carry the specific request 
information to the target DSP, and the DSI reply to 
carry the information/response to the origin DSP. 

Based on the definitions of DSPs discussed 
above, the following relationship can be construct- 
ed to depict the message flows among DSPs -P- 
(U), P(F), P(D) and P(N). 

Figure 10 shows the DSI request flows among 
DSPs. The possible flows are: (1) P(U) -P(F), (2) P- 
(F) -P(F) by way of P(N)s. and (3) P(F) -P(D). 
Figure 11 shows the DSI reply flows among DSPs. 
The possible flows are: (1) P(D) -P(F), (2) P(F) -P- 
(F),and(3)P(F)-P(U). 



Usage of Protocol Boundaries 

Thus, the present system definies one protocol 
boundary for its users and uses three different 
protocol boundaries to formally describe the sys- 
tem structure. A DSU provides the protocol bound- 
ary for the user to send the directory requests to 
DSU and receive the directory 
information/response from DSU. DSU uses the pro- 
tocol boundary of a communication network to 
communicate with another DSU in another system. 
Another protocol boundary is used by DSU to 



control accesses to and read and write the data in 
a directory data model. Th functions of these 
v rbs may be implemented in a product unique 
manner. 

5 In connection with Figs. 13 and 14 illustrating 

the processing sequence for update and query 
propogation. respectively, there are separate pro- 
cessors shown for update reply, update request, 
query reply and query request However, if a given 
to DSU is not involved in query propagation, only the 
update processors are required. 

As shown in Fig. 15, the present invention 
employs a directory operation control block. The 
operation control block contains informations which 
75 controls the directory system functions performed 
on behalf of the user. This component includes 
search (query) algorithm control information, and 
internal tables which define the relationship of this 
member user directory with other members (at 
20 other DSUs) within a particular directory database. 

The directory operation control block shown in 
Fig. 15 supports directory system services such as 
automatic search and automatic maintenance to the 
user. This control block is associated with a par- 
25 ticular member of the directory database, and the 
information contained therein is location-dependent. 
This control block is usually initialized by way of 
directory system generation parameters, although 
changes to internal operation of the directory sys- 
30 tern fo this member may occur dynamically 
through the protocol boundary. 

The directory operation control block contains 
the affinity list search algorithm control field, integ- 
rity parameters field, and access control field, 
as which can be described as follows. 

Affinity U£: "Pie affinity list describes the logi- 
cal relationship between this member and other 
members of a particular directory database. The 
affinity list data values describe whether other di- 
40 rectory database members are superiors, peers, or 
subordinates to this member. The manner in which 
directory data is distributed, and logically config- 
ured, can therefore be derived from affinity list data 
values. A consequence of affinity list design en- 
45 ables a reconfiguration of user data (say, from a 
centralized to a distributed configuration) by subse- 
quent changes to affinity list data values. 



This field supports various user options of the 
automatic name resolution function. Such options 
may include action to be taken by the DSU upon 
55 determining a "not f und" condition at this mem- 
ber, such as report an "error*, continue searching 
using internal search alg rithms, or return a data 
value to the user. 



so Search Algorithm Control 
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There may be cases where a cascaded search 
is possible using participating members' affinitiy 
tables. Similarly, some members who do not sup- 
port this capability can terminate the search from 
continuing beyond this point; this may be useful to 
support products of varying capabilities in a depth- 
first search algorithm. 



Integrity Parameters 

Degrees of error tolerance, or of consistency of 
user data within the distributed directory database, 
are supported by means of the integrity parameters 
field. These can be described by the user at im- 
plementation. 



The User-DSU Interface 

The protocol boundary verbs (API) used in the 
query functions may include the following which 
are described in rough functional form. The de- 
scription is meant only to provide sufficient detail to 
enable the understanding of the query mechanisms 
that will be described subsequently, and is not in 
any sense meant to be exhaustive. 

The parameters that can be specified for a 
query request include the following: 

Input Search Argument (typically, the name of the 
object) Directory Type ID 

Information Desired 

Whether the query is to be local only. 

There are two basic ways the query mecha- 
nisms can be described; directed and undirected. 



THE DIRECTED QUERY MECHANISM 

This is the simplest query mechanism, and in it 
the user specifies the identity of the DSU to which 
the query message muste be sent-the target DSU. 
The DSU to which the user is attached (the source 
DSU) would then use the transport mechanism to 
send a message to the target DSU. The target DSU 
would receive this message, perform the necessary 
operations on its local directory and respond as 
appropriate. The target DSU would not propagate 
the message to any further remote DSU. 

Figure 16 depicts an example of the use of a 
directed query. It wille be noted that the use of a 
directed query does not imply physical adjacency 
of source DSU and target DSU. The mechanism 
can be used where the user knows the target DSU 
and the underlying transport provides a commu- 



nication path to the target DSU. The mechanism 
cannot be used if either of the above conditions are 
not satisfied. While the second condition may be 
satisfied in many environments, it is probably un- 
s likely that the user will know the identity of the 
target DSU. Special" cases where the user has this 
information may include: 

1. The user obtains this information through 
some mechanism defined by the user. An example 

10 of this mode of operation is if the name of the 
object contains the identity of the target DSU. 

2. A directory service can maintain a special 
directory which contains the identities of the target 
DSUs for certain objects in the network. The user 

75 would query this special directory, obtain the target 
DSU information, and then initiate a directed query. 
This special directory may also be maintained 
through one of the query/update mechanisms. Fig- 
ure 17 depicts an example of the use of this 

20 special directory. 

If either condition described above does not 
prevail, or if it desired that target DSUs propagate 
the query further, the directed mechanism cannot 
be employed. 

25 

THE UNDIRECTED QUERY MECHANISM 

In the undirected mechanism, the user does 

30 not provide the identity of the target DSU. Instead, 
the propagation of queries is guided by data struc- 
tures known as propagation tables or P-tables. 
Each DSU maintains, for each directory type, a P- 
table which determines, for that directory type. 

35 which other DSUs to send query messages to. 

Upon receipt of an undirected query, the 
source DSU consults its P-table for that directory 
type and. based on the information contained in the 
P-tables, sends a query message to one or more 

40 DSUs. The DSUs that receive the message consult 
their own P-table and may propagate the query 
further. Figure 18 depicts a typical example of this 
type of query propagation. 

The fact that the receiving DSU may propagate 

45 the message further creates two possible causes of 
incorrect operation. Firstly, there is the possibility 
that the query sent to one DSU. (DSU B in the 
example shown in Fig. 18). is not propagated while 
the query sent to another DSU is propagated (DSU 

so C), resulting in the response from one DSU arriving 
very much before the response from the other. 
Incorrect operation may result if the source DSU 
responds to the user and erases any memory of 
the query immediately after the first response. 

55 
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Secondly, there is the possibility that query 
messages may 'loop'. For example in Figure 19, 
the P-tables are set up so that DSU A sends 
queries to DSU B, and DSU B send qu ri s to DSU 
C. If no mechanism was in place to prev nt loop- 
ing, queries could bounce back and forth between 
the two DSUs forever. 

The mechanism that will be described in the 
following sections solves the above problems by 
creating a special control block for each query and 
maintaining that control block untH'propagation has 
terminated. Further details are discussed below 
under "The Basic Query Propagation Mechanism". 



P-Tables 

The P-tables at the various DSUs define how 
the DSUs interact with one another in performing 
queries. Each DSU in the network contains P-tables 
for every directory type for which it may perform 
undirected queries. The P-table in a DSU contains 
the identities of some of the other DSUs in the 
network. It must be possible to establish a commu- 
nication path with any DSU that appears in a P- 
table. 

The P-table consists of two parts, a query P- 
table (QP-table) and an update P-table (UP-tabte). 
Additional description of the function and use of the 
update P-tables is contained in the above-referen- 
ced copending application (A3). Additional descrip- 
tion of the directory control block and the query 
control •block used in query propagation is con- 
tained in the above-referenced copending applica- 
tion (A2). The QP-table defines the DSUs to which 
queries are sent. The structure of the tables is 
shown in Figure 20. In addition to containing the 
identities of the DSUs these tables define the order 
in which the DSUs are queried, by specifying a 
numeric parameter or priority associated with each 
DSU. The DSU with the highest priority is sent the 
query message first, while DSUs with equal priority 
receive the messages in parallel. As Figure 20 also 
depicts, there is an extra algorithm control field 
associated with each DSU entry. 

The following describes the processing of que- 
ries and updates, with or without propagation. The 
different cases involved in such processing include: 

Query Processing at the origin DSU without 
propagation -the origin DSU receiving the query 
request from the user satisfies the request from the 
locally residing directory without propagation. 

Query Processing at the origin DSU with prop- 
agation. The origin DSU cannot locally satisfy the 
request from the user and, therefor , originates the 
query request for propagation to other remote 
DSUs. 



Query Processing at th intermediate DSU - 
The intermediate DSU receiving a query request 
from the r mote DSU cannot satisfy the request 
and, therefore, propagates the query request fur- 
5 ther to other DSUs. 

Query Processing at the target DSU -The tar- 
get DSU receiving a query request retrieves the 
requested data and send the query reply toward 
the origin DSU. 

io Update Processing at the origin DSU -The ori- 
gin DSU receiving an update request from the user 
originates the update request for the propagation to 
the DSUs to be affected. 

Update Processing at the intermediate DSU - 

75 The intermediate DSU receiving an update request 
from the remote DSU propagates the update re- 
quest further to other DSUs to be affected. 

Each case will be described separately by con- 
sidering only those components of the directory 

20 system structure that are required to process the 
given case. In the drawings, solid lines with arrows 
denote procedure CALLS. Dotted lines with arrows 
denote the execution of the protocol boundaries or 
the access of the control data block. Figure 14 

25 illustrates the directory system model for the query 
processing, while Figure 13 illustrates the directory 
system model for update processing. 



30 QUERY PROCESSING CASES 

Query Processing at Origin DSU (No propagation) 

The processing steps include: 
35 1. The application program calls the API_ 

Query Send Processor to pass the QUERY verb. 

2. The API__ Query_ Send validates its 

syntax and parameters. The API Query Send 

calls the DSI Query__RQ processor to pass the 

40 Query request for processing. 

3. The DSI__ Query_ RQ processor calls 
the Data_Read processor to request the data. The 
Data_Read processor retrieves the requested di- 
rectory data by managing the data access protocol 

45 boundary according to the directory descriptors, 
and returns the retrieved data to the 
DSI Query^RQ. 

4. The DSI_Query_RQ constructs the DSI 
query reply which carries the retrieved data, and 

so calls the DSI__Query__Reply processor to pass the 
query reply. 

5. The DSI_Query_Reply processor man- 
ages the finite state machines associated with the 
query request, and calls the API_Query__R ply 

55 processor to present the r suits of th query to the 
application program. 
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6. The API_Query_Reply Processor de- 
codes the DSI query reply and places the resulting 
data into the queue. 

Control is eventually returned to the - 
API_Query_Send. At this time, the s 
API_Query_J>end returns control with the return 
code ("successful") to the application program. 



Query Processing at the origin DSU (Propagation) io 

The processing for the case where the origin 
DSU cannot satisfy the query request from the 
local directory, thus originating the DSI query re- 
quest for propagation to other remote DSUs, is as 75 
follows: 

1. The application program calls the 
API_Query__Send Processor to pass the QUERY 
verb. 

2. The API__Query Send validates its syn- 20 

tax and paramemeters ters. The 

API Query_Send calls the DSI__Query__RQ pro- 
cessor to pass the Query request for processing. 

3. The DSI_Query_RQ processor calls the 
Data_Read processor to request the data. The as 
Data_Read processor returns an indication that it 
cannot find the requested data from the local direc- 
tory. 

4. The DSI__Query RQ calls the Query Al- 
gorithm which is one of the Directory alogorithm 30 
facilities. The query algorithm determines which 
DSU to send the DSI query request to for remote 
search. 

5. The DSI_Query_RQ places the destina- 
tion DSU name (which indicates the next DSU for 35 
the request to be delivered to) in the appropriate 
field of the DSI query request, and calls the 
Data__Send processor to send the DSI query re- 
quest through the network. 

6. The Data_Send processor manages the 40 
network protocol boundary for proper delivery of 

the DSI query request to the destination DSU. At 
this time control will be returned to the 
API_Query_Send through the DSI_Query_RQ. 
and API_Query_J>end returns control with the re- 4s 
turn code ("successful") to the application pro- 
gram. 

7. The Data__Receive processor receives 
the DSI query reply carrying the requested data 
from the remote DSU through the network protocol so 
boundary. 

8. The Data__Receive processor calls the 
DSI__Query_Reply processor to pass the DSI 
qu ry reply received from the remote DSU. 

9. The DSI__Query_Reply processor man- 55 
ages the finite state machines associated with the 
query r qu st, and calls the API_Query_Reply 
processor to present the results of the query to the 



application program. Optionally, the results of the 
query can be retained in th local directory by 
calling the Data__Write processor. 

10. The API__Query_Reply Processor de- 
codes the DSI query reply and places the results of 
the query into the queue. Optionally, application 
program is scheduled for each enqueued query 
result 



Query Processing at an Intermediate DSU 

The processing for the case where the inter- 
mediate DSU receives a DSI query request but it 
cannot service the query request from the local 
directory, thus sending the DSI query request for 
propagation to other remote DSUs, is as follows: 

Processing steps: 

1. The Data__Receive processor receives 
the DSI query request from the remote DSU 
through the network protocol boundary. 

2. The Data__Receive processor calls the 
DSI Query RQ processor to pass the DSI query 
request received from the remote DSU. 

3. The DSI Query_RQ processor calls the 

Data_Read processor to request for the data The 
Data__Read processor returns an' indication that it 
cannot find the requested data from the local direc- 
tory. 

4. The DSI Query RQ calls the Query Al- 
gorithm to determine which is the next DSU for 
query propagation. 

5. The DSI__Query__RQ places the destina- 
tion DSU name in the appropriate field of the DSI 
query request, and calls the Data__Send processor 
to send the DSI query request through the network. 

6. The Data_J>end processor manages the 
network protocol boundary for proper delivery of 
the DSI query request to the destination DSU. 



Query Processing at Target DSU 

The processing for the case where the target 
DSU receives a DSI query request from a remote 
DSU, retrieves the requested data from the local 
directory and sends the DSI query reply toward the 
origin DSU is as follows: 

Processing steps: 

1. The Data Receive processor receives 

the DSI query request from the remote DSU 
through the network protocol boundary. 

2. The Data__Receive processor calls the 
DSI_Query__RQ processor to pass the DSI query 
request received from remote DSU. 

3. The DSI Query RQ processor calls the 

Data__Read processor to request for the data. The 
Data__Read processor retrieves the requested di- 
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rectory data by managing the data access protocol 
boundary according to the directory descriptors, 
and returns the retrieved data to the 
DSI_Query RQ. 

4. Th DSI_Query_RQ constructs the DSI 5 
query reply which carries the retrieved data, and 
calls the Data_Send processor to send the DSI 
query request through the network. 

5. The Data__Send processor manages the 
network protocol boundary for proper delivery of w 
the DSI query request to the destination DSU. 



Creation of P-Tables 

The entries in each P-table may be created in 
several different ways. They may be linked directly 
to the way in which data is distributed through the 
system, something which may be specified in the 
form of an affinity table. 20 

Alternatively, the P-tabtes may be defined di- 
rectly at system generation time and remain un- 
changed through the entire directory operation tion, 
or may be updated dynamically. They may also be 
created during operation or through other mecha- 25 
rtisms such as queries to a 'directory of directories' 
or through input from the network routing function. 

Access of P-Tables 30 

Furthermore, the protocol boundary may permit 
only indirect access to the P-tabtes. The indirection 
is in that the user does not specify the actual 
entries in the P-tables. but. instead, specifies the 35 
way in which he wants data distributed through the 
network using certain data distribution primitives. 
These notions are then translated automatically into 
entries in P-tables. 

The advantage of this indirect approach is that 40 
it enables the user to think of the directory struc- 
ture only in terms of data distribution, something 
that is intuitive and easy to understand, while 
shielding him from the complexities of understan- 
ting the flow of queries. The disadvantage of this 45 
approach is that it limits flexibility and prevents the 
user from exercising the full range of query propa- 
gation options that is possible if direct access to 
the P-tables is permitted. 

so 
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DATA DISTRIBUTION PRIMITIVES 

The user may define some data distribution 
relationships between the DSUs in the network. 
This section describes the relationships, how they 
are used to set up a directory service system, and 
how these relationships then get translated into P- 
table entries. 

In understanting the motiviation behind the 
translation, rt is important to understand the 
"duality" between queries. In particular, if DSU A 
always sends an update to DSU B whenever it 
changes its directory, there is no necessity for DSU 
B to ever query DSU A. Conversely, if DSU B 
always queries DSU A. there is no necessity for 
DSU A ever to send updates to DSU B. The 
translation from data distribution to P-table entries 
is designed to take this "duality" into account and 
thus to conserve on the use of communication 
bandwidth. 

The relationships are with respect to a specific 
directory type ID. It is possible and indeed likely 
that the relationship for different directory type ID's 
will be quite different The following data distribu- 
tion relationships can be defined: 



Sup-Sub Relationship 

The superior (SUP)-subordinate (SUB) relation- 
ship is depicted pictorially in Fig. 21 by a directed 
arc from A to B. A is the SUB and B is the SUP. 
The relationship is established by specifying at A 
that B is a SUP of A and by specifying at B that A 
is a SUB of B. This relationship implies that under 
"normal" conditions a communication path exists 
from the SUB to the SUP through the transport 
mechanism. In terms of data distribution, it implies 
that if X is the directory type ID for which this 
relationship has been defined, then B's directory of 
type ID X is a superset of A's directory of the same 
type ID. 

The translation into P-table entries attempts to 
preserve the nature of the relationship. As B is the 
SUP of A, both queries are propagated from A to 
B. However, as B's directory contains all the in- 
formation that A's directory contains, B neither que- 
ries nor updates A. The translation to P-table en- 
tries in A and B is depicted in Figure 22. 



Peer-Peer Relationship 

As shown in Fig. 23, this relationship is de- 
picted pictorially by an undirected arc between th 
PEERs. The relationship is established by specify- 
ing at A that B is a PEER of A and by specifying at 
B that A is a PEER of B. This relationship implies 
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that th PEERS can communicate with each th r 
through the transport mechanism and that the user 
would like them to communicate directly in order to 
perform directory functions. It does not imply any 
relationship in terms of data distribution. Thus, in 
the translation to P-table entries, queries are ex- 
changed between PEERs, as represented in Fig. 
24. 



Replicated Relationship 

This relationship is depicted pictorially in Fig. 
25 by a bidirectional arc between the DSUs. The 
relationship is set-up by specifying at A that B is a 
REPLICATE of A and by specifying at B that A is a 
REPLICATE of B. This relationship implies that the 
DSUs can communicate with each other through 
the transport mechanism. In terms of data distribu- 
tion, it is equivalent to two SUP-SUB relationships; 
that is, B is a superset of A and A is a superset of 
B. Clearly, this can be satisfied only if A and B are 
identical. The translation to P-table entries is de- 
signed to preserve the replication by propagation 
updates between the DSUs as represented in Fig 
26. It will be apparent that many other types of 
relationships are possible. 



Other Relationships 

The examples shown in Figs. 27-30 illustrate 
that the definition of relationships between the 
DSUs in a network determines the data distribution. 
It will be noted that the relationships define a 
network over which queries are normally propa- 
gated. This network is usually a sub-network of the 
network formed by defining all possible commu- 
nication paths. In other words, there may be com- 
munication paths available between DSUs which 
are not normally used in query propagation. 



PRIORITIES OF THE ENTRIES 

It has been shown how the data distribution 
primitives defined get mapped into entries in the 
QP-table and the UP-table. It needs to be shown 
how the priority of these entries is established. 
Consider the UP-table. Clearly, ft is advantageous 
to propagate in parallel to all SUP DSUs, as this 
would enable the update to reach the appropriate 
destinations as soon as possible. Thus, in the 
translation to P-table entries, all entries are given 
equal weight as shown as an example in Fig. 31. 



Considering th QP-tabl , both SUPs and 
PEERs are entered into the table. In propagating 
queries, it is not the case that parallel propagation 
is always desirable. In some instances, sequential 

5 propagation may be preferable as it may result in 
less bandwith being used in query propagation. 
Thus, two basic methods, the parallel and the se- 
quential, are provided for in constructing P-tables. 
The choice of parallel or sequential can be con- 

io trolled at the time of system definition. 

The parallel approach is very similar to that 
used in the construction of the UP-tables. All SUP 
entries are given equal priority and all PEER en- 
tries are given equal priority. The priority of the 

75 SUPs, however, is higher than the priority of the 
PEERs (that is, a smaller numerical value). For 
reasons that will become apparent when the al- 
gorithms are described, the SUPs are assigned a 
negative number as priority. Fig. 32 shows an 

20 example of this. 

This sequential propagation approach assigns 
priority number to the DSUs in ascending order, 
with the SUPs having the smaller numbers, (again 
chosen to be negative), and the PEER'S the larger 

26 number (positive). Fig. 33 depicts this through an 
example. 

The determination of whether parallel or se- 
quential propagation is used is usually made at 
create-configuration time or automatically by 
30 means of a predefined user algorithm. It is impor- 
tant that all the DSUs that participate in a given 
query use the same mode of propagation. Thus, it 
is not permitted for the originating node to propa- 
gate a query in a sequential fashion and for inter- 
as mediary nodes to relay that query in parallel fash- 
ion. In order to ensure this, the query messages 
that are propagated in the network contain a bit 
which indicates whether the DSU that initiated the 
query used sequential or parallel propagation. 
40 Intermediary nodes use the method of propa- 
gation indicated in the query message, thereby 
ignoring the priorities in the QP-table, and creating 
a new set of priorities if the query message speci- 
fies a different mode of propagation than the mode 
4$ for which their QP-tables are set up. 



RELATIONSHIP RULES 

so The relationships of the DSUs in the network 
for a given directory type ID should satisfy certain 
rules. These rules are important in order to main- 
tain internal consistency of the P-table in a given 
DSU, as well as in the relati nship between P- 

55 tables in different DSUs. The rul s are as follows: 
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2. Ther exists a DSU C so that there are 
paths consisting ntir ly f directed arcs, trav rsed 
in the indicated direction, from both A and B to C. 
Note that a degenerate case where this condition 
would be satisfied would be rf there was a directed 
path from A to B or vice versa 

In order for the propagation algorithms not to 
use an unecessarily large amount of bandwidth, 
only one of 1 and 2 above must hold. 

If B is PEER(A), then D cannot be SUP(A) or 
REPUCATE(A). Similary, rf B is SUP(A), then B 
cannot be PEER(A) or REPLICATE(A); and 

PEER relationships are always reciprocal. Simi- 
larly, if B is SUP(A) then B cannot be PEER(A) or 
REPUCATE(A) and if B = REPLICATE (A) then it 
cannot be PEER(B) or SUP(A). 



THE BASIC QUERY PROPAGATION MECHANISM 

This is shown in block diagram form in Fig. 14. 
The query message sent between the DSUs con- 
tains all the information that initiated the query, and 
in addition, the identification of the DSU that origi- 
nated the propagation of the query (the source 
DSU), and a correlation number which is generated 
by the source DSU. Fig. 34 shows a typical query 
message. Any response message contains the in- 
formation generated in response to the query and, 
importantly, also includes the identification of the 
DSU that was the source of the query and the 
correlation number contained in the query. Fig. 35 
shows a typical query response message. 

The combination of source DSU identification 
and correlation number is used by the various 
DSUs in the network to uniquely identify that query 
and to correlate responses to the query with the 
query itself. The DSU identities are required to be 
unique. In order for the combined DSU identity 
plus correlation number to be unique, It is neces- 
sary for the source DSU to ensure that it uses a 
correlation number only if it is certain that no 
instance of any previous query message that it 
may have generated with the same correlation 
number remains in the network. 

A practical method of achieving this is to use 
as a correlation number a time-stamp or a con- 
stantly incremented sequence number, taking care 
to ensure that the size of the correlation number 
field and therefore, the time between wrapping of 
the number, is large. The propagation of query 
messages is guided by the P-tables for that direc- 
tory type at each DSU. 



SUMMARY 

It has beeen successfully demonstrated that 
queries can be propagated across any network 

5 environment or topology. Ether theses queries can 
be directed to a target or undirected (automatic) by 
means of the use of P-tables. 

P-tables define relationships (SUP-SUB. PEER- 
PEER, etc.) between directory units (DSUs), wheth- 

io er they are local or remote. Based on priority and 
the type of propagation desired (sequential or par- 
allel), queries are sent to participating DSUs. In 
addition, the mechanisms also provide for the user 
to specify his own algorithms to either propagate 

is queries or determine the mode. The mechanisms 
thus described provide for both uni-and bi-direc- 
tional query propagation. Inherent in these mecha- 
nisms is the performance criteria to reduce looping 
and audit trails for recovery. 

20 



Claims 

1. In a directory database system including a 
25 network having a plurality of communication paths 
and a plurality of directory service units (DSU). 
each of said DSUs providing one or more directory 
service functions within said directory database, an 
apparatus for propagating a user query relative to 
30 an object from a source DSU to a target DSU 
comprising : 

a special directory containing the identities of tar- 
get DSU's for certain of said objects in said net- 
35 work, 

means for communicating said user query from 
said source DSU to said special directory means 
for generating information identifying the target 
40 DSU for said object embodied in said query, and 

means for communicating said information relative 
to said identified target DSU to said source DSU. 
2. In a directory database system including a 

45 network having a plurality of communication paths 
and a plurality of directory service units (DSU), 
each of said DSUs providing one or more directory 
service functions within said directory database, an 
apparatus for propagation of an undirected user 

so query relative to an object from a source DSU to 
one or more target DSUs. which target DSU may 
contain information relative to said object, compris- 
ing : 

55 - a propagation (P) table in each of said DSUs. 
ach f said P tables being a data structur ca- 
pable f d termining which other DSU's to send 
said user query to, 
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•means in said source DSU for examining its asso- 
ciated P table for the directory type specified in 
said query to generate an identification of one or 
more, additional target ones of said DSUs to which 
said query should be directed, s 

-means for propagating a query from said source 
OSU to those additional DSU's identified by said P 
table in said source DSU, and 

70 

-means for returning to said source DSU informa- 
tion responsive to said user query from the one of 
said additional target DSU's containing said in- 
formation. 

3. Apparatus in accordance with Claim 2 in- 75 
eluding means in each of said additional DSU's for 
examining its P table to determine the identity of 

the target DSU to which said query should be 
directed. 

4. Apparatus in accordance with Claim 2 in 20 
which each of said P tables includes a query P- 
table (QP-table) and an update P-table (UP-table). 

5 Apparatus in accordance with Claim 4 in 
which said QP table defines the one or more target 
DSUs to which a query should be sent 2s 

6. Apparatus in accordance with Claim 5 in 
which each of said QP tables contain information 
determining the order in which any additional target 
DSUs are to be queried. 

7. Apparatus in accordance with Claim 4 in 30 
which each of said QP tables in each particular one 

of said DSUs defines the status relationship of said 
particular DSU to other DSUs of the same directory 
type. 

8. Apparatus in accordance with Claim 7 in as 
which the QP table in said particular DSU defines a 
superior-subordinate relationship between said par- 
ticular DSU and one or more of said other DSUs. 



9. Apparatus in accordance with Claim 7 in 
which the QP table in said particular DSU defines a 
peer-peer relationship between said particular DSU 
and one or more of said other DSUs. 

10. Apparatus in accordance with Claim 7 in 
which the QP table in said particular DSU defines a 
replicated relationship between said particular DSU 
and one or more of said other DSU's. 

11. Apparatus in accordance with Claim 5 in 
which each of said QP tables determines whether 
further propagation of a query to a plurality of other ■ 
DSU's is to be in a serial or a parallel mode. 

12. Directory service system having a plurality 
of irrterconnectable directory service units (DSU), 
characterized in that it comprises a plurality of 
processes within said directory service system, 
said plurality of processes including: 

-a P(U) process for interfacing with a user of said 
system at a user protocol boundary; 

-a P(D) process for Interacting with a directory 
database at a directory data access protocol 
boundary; 

-a P(N) process for interacting with a communica- 
tion network at a network control boundary; and 

-a P(F) process for interacting with at least one of 
the other of said processes in said directory ser- 
vice system. 

13. Directory service system in accordance 
with Claim 12 in which each of said processes is 
located in one of said DSUs. 

14. Directory service system in accordance with 
Claim 13 in which said directory database with 
which said P(D) process interacts is accessible by 
said P(D) process from the one of said DSUs in 
which said P(D) process is located. 
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